\subsection{Les points d'extensions}
\label{sec:extensions_point}

Comme introduit précédemment l'exploitation des données d'un profil de suivi est
réalisé à partir d'un éditeur organisé en onglets; chaque onglet présentant un
aspect particulier du suivi.

Un onglet présente ses informations dans ce que l'on a appelé une \emphbf{page}.
On a donc distingué deux types de page:
\begin{itemize}
  \item Des pages exploitants le modèle de données partagé présenté dans la
  section \ref{sec:mig_data_model}.
  \item Des pages responsables du calcul des informations qu'elles affichent.\\
\end{itemize}

\begin{figure}[H]
\lstset{language=XML}
\centering
\begin{lstlisting}
   <extension
         point="com.migration.platform.plugin.main.editorTabs">
      <editorPage
            page="com.migrationplatform.plugin.main.editors.ScenariosPage"
            pageId="com.migrationplatform.plugin.main.editors.ScenariosPage"
            pageName="Scenarios">
      </editorPage>
      <standalonePage
            page="com.migrationplatform.plugin.main.editors.CallsPage"
            pageId="com.migration.platform.plugin.main.callsView.page"
            pageName="Appels">
      </standalonePage>
   </extension>
\end{lstlisting}
\caption{Point d'extension: ajout de pages dans l'éditeur de
profil}\label{cod:add_page_via_extension}
\end{figure}

La figure \ref{cod:add_page_via_extension} représente un extrait du fichier
\emphbf{plugin.xml} d'un plugin \textsc{Eclipse} permettant de rajouter des
pages dans l'éditeur d'un profil. L'extension est constituée des éléments qui
suivent:
\begin{itemize}
  \item Un identifiant unique du point d'extension\\
  \emphbf{com.migrationplatform.plugin.main.editorTabs}.
  \item La déclaration des deux types de pages, \emphbf{editorPage} pour les
  pages dépendantes du modèle et \emphbf{standalonePage} pour les pages non
  dépendantes du modèle.
  \item Chaque page possédant des attributs la caractérisant: \begin{itemize}
    \item \emphbf{page}: La classe gestionnaire de la page.
    \item \emphbf{pageId}: Un identifiant unique pour la page.
    \item \emphbf{pageName}: Le nom affiché dans l'onglet présentant la page.\\
  \end{itemize}
\end{itemize}

Le diagramme \ref{fig:migration_page_model} montre comment sont intégrées au
code du plugin, les pages déclarées via point d'extension. On peut y observer les
éléments suivant:\\
\begin{itemize}
  \item \emphbf{BasicConfigurationPage}: C'est le point d'entrée de notre plugin
  vers l'API \\\emphbf{org.eclipse.ui.forms} utilisée pour la mise en place de
  l'éditeur de profil. Toutes les pages de notre éditeur sont représentées par
  cette classe.
  \item \emphbf{ConfigurationOverviewPage}: Exemple de page non déclarée via
  point d'extension et donc toujours présente dans l'éditeur. Il s'agit ici de
  la page de synthèse (voir \ref{fig:mpp_overview}).
  \item \emphbf{MigrationFormPage} : Est le point d'entrée des pages déclarées
  via point d'extension, qui référencie l'interface \emphbf{IMigrationFormPage}
  que doivent implémenter tous les gestionnaires des pages crées via point
  d'extension.
  \item \emphbf{IFormPageWithModel} : Interface représentant les pages
  dépendantes du modèle.
  \item \emphbf{IStandalonePage} : Interface représentant les pages non
  dépendantes du modèle.
  \item \emphbf{AbstractTreeModelPage} : Classe que peuvent étendre les pages
  souhaitant présenter les données du modèle sous forme d'un arbre. Ces
  dernières devront implémenter l'adaptation du modèle selon leurs
  besoins avant son affichage. C'est dans cette classe que sont mises en oeuvre
  des mécanismes tels que le filtrage des éléments affichés ou encore
  l'implémentation d'actions sur une sélection de noeud de l'arbre.\\%
\end{itemize}

\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{images/migration_page_model2.png}
\caption{Extrait modèle de page de l'éditeur de
profil}\label{fig:migration_page_model}
\end{figure}

Le schéma \ref{fig:seq_migration_form_page_model_change} montre un exemple de
scénario pouvant survenir lors de la modification du modèle de suivi de profil
courant. Le point d'entrée du scénario est la réception du signal de
modification du modèle, il met en évidence la mise à jour des pages déclarées
via le point d'extension en s'attardant sur les pages de présentation sous forme
d'arbre et la phase adaptation du modèle avant sa présentation.

\begin{landscape}
\begin{figure}[h]
\centering
\includegraphics[width=\paperwidth]{images/seq_migration_form_page_model_changed3.png}
\caption{Point
d'extension: mise à jour des pages lors d'un changement de modèle}
\label{fig:seq_migration_form_page_model_change}
\end{figure}
\end{landscape}

\subsection{Un wizard pour la création de profil}
\label{ref:wizard_creation_profil}

Dans sa version initiale la création d'un profil de suivi se déroulait en
fournissant le nom du profil, puis la configuration se réalisait par
l'intermédiaire de la page d'édition de profil créée à cet effet (voir
l'illustration \ref{fig:mpp_profile_editor}).

Les retours d'essais sur l'utilisation de la plateforme ont montré que ce
processus de création de profil n'était pas facile à prendre en main du fait du
nombre d'informations à fournir pour une configuration complète. Il a donc été
décidé de disposer d'un Wizard pour la création de profil permettant de
bénéficier des avantages suivant:
\begin{itemize}
  \item L'intégration dans l'API Wizard d'eclipse.
  \item La factorisation des données de suivi par point d'intérêt, permettant à
  l'utilisateur de disposer d'un processus de création clair et guidé.
  \item Un meilleur contrôle des données de configuration.\\
\end{itemize}

\subsubsection{L'API Wizard d'eclipse}
\label{sec:eclipse_wiz_api}

\textsc{Eclipse} met à la disposition des développeurs une API permettant la
création et l'intégration de \textit{wizard}.

\begin{figure}[H]
\centering
\includegraphics{images/eclipse_wiz_api.png}
\caption{Résumé API wizard d'\textsc{\Gls{eclipse}}}\label{fig:eclipse_wizard_api}
\end{figure}

Le schéma \ref{fig:eclipse_wizard_api} résume l'API Wizard d'\textsc{\Gls{eclipse}}.
Un wizard est représenté par une interface \emphbf{IWizard} et propose une
navigation par pages à travers un ensemble d'implémentation de l'interface
\emphbf{IWizardPage}. \textsc{\Gls{eclipse}} facilite la création de wizard en
proposant les implémentations \emphbf{Wizard} et \emphbf{WizardPage}, ne
laissant à la charge du développeur que la gestion des données présentées sur
chaque page et l'action à exécuter lorsque toutes les étapes ont été
franchies.

\subsubsection{L'API Wizard pour la création de profil}

En plus d'étendre l'API Wizard fournis par \textsc{Eclipse} les pages
définies pour notre \textit{Wizard} de création de profil doivent réaliser une
autre interface introduite par nos soins. Il s'agit de l'interface
\emphbf{IProfileCreationParticipant} (voir extrait \ref{cod:i_profile_creation_participant}).

\begin{figure}[H]
\lstset{language=Java}
\centering
\begin{lstlisting}
/**
 * An interface to describe participants to a configuration creation.
 * 
 * @author hesteguet
 * 
 */
public interface IProfileCreationParticipant {

	/**
	 * Populates the configuration.
	 * 
	 * @param config
	 */
	void populate(Profile config);

	/**
	 * 
	 * @return <code>true</code> If the participant is satisfied by its participation
	 */
	boolean isSatisfied();

}
\end{lstlisting}
\caption{Interface des participants à la création d'un profil de
suivi}\label{cod:i_profile_creation_participant}
\end{figure}

L'intérêt de l'introduction de cette interface est résumé par les faits
suivant:
\begin{itemize}
  \item Chaque participant s'occupe d'une partie des données du profil, qu'il
  peut ensuite renseigner à la fin du processus grâce à la méthode
  \emph{populate}.
  \item Le processus de création du profil ne pourra être validé que si tous
  les participants sont satisfaits par les données que leur auront fournis les
  utilisateurs. De même le passage d'un participant à l'autre ne sera autorisé
  que si le participant courant est satisfait.\\
\end{itemize}

\begin{landscape}
\begin{figure}[h]
\centering
\includegraphics[width=\paperwidth]{images/Class_Diagram__data__Actions__ActionsDiagram.png}
\caption{Diagramme de classes modélisant les actions d'une application}
\label{fig:class_diagram_actions}
\end{figure}
\end{landscape}

\subsection{Le graphe d'appels des méthodes}
\label{sec:call_graph}

L'extrait du modèle de cartographie illustré par le diagramme
\ref{fig:class_diagram_actions}, représente la modélisation des actions d'une
application. Comme on peut l'observer on dispose de plusieurs types d'actions,
son exploitation dans la plateforme développée se limite aux appels réalisés
par les méthodes (\emphbf{CallAction}). Le but étant de donner une idée de la
complexité d'une méthode de par le volume de code qu'elle appelle.


\begin{figure}[H]
\centering
\includegraphics[width=0.65\textwidth]{images/calls_graph.png}
\caption{Exemple de graphe d'interaction entre des
méthodes}\label{fig:call_graph}
\end{figure}

Le graphe représenté par le schéma \ref{fig:call_graph} est un exemple d'appels
entre un ensemble de méthodes étiquetées de m1 à m7. On peut y faire plusieurs
observations importantes:
\begin{itemize}
  \item Il s'agit d'une représentation statique, c'est à dire que l'on ne
  s'intéresse pas à l'enchaînement des appels, mais aux appels déclarés dans le
  corps de la méthode. Ainsi les successeurs d'un noeud dans le graphe ne
  représentent pas forcement les différents chemins que l'on peut emprunter lors
  de l'exécution de la méthode.
  \item Le graphe d'appels peut très vite devenir fortement cyclique, il est
  donc nécessaire de définir un point d'arrêt dans son parcours lors du calcul du
  volume de code appelé.
  \item On définit le volume de code appelé par une méthode de manière récursive
  comme étant, son nombre de ligne de code augmenté du volume de code appelé par
  toutes les méthodes qu'elle appelle.
  \item Ces données sont présentées aux utilisateurs sous forme d'arbre,
  permettant ainsi d'afficher au niveau de chaque noeud les informations que
  l'on souhaite (ici le volume de code appelé). Cette présentation de données
  est mise en oeuvre grâce aux mécanismes présentés dans la section
  discutant des points d'extensions (voir \ref{sec:extensions_point}).
  \item Le schéma \ref{fig:call_tree} montre une partie de l'arbre présenté à
  l'utilisateur et calculé à partir du graphe \ref{fig:call_graph}. On peut
  constater qu'un tel déroulage du graphe, en évitant les cycles, peut avoir une
  empreinte mémoire importante selon la taille du code analysé et du niveau
  d'interaction entre les différentes méthodes. La difficulté technique dans la
  réalisation de cette vue, est l'utilisation d'un modèle sans redondances de
  données représenté en mémoire par un graphe tel que celui montré par la figure
  \ref{fig:call_graph}; mais présenté dans la vue sous forme d'arbre.
\end{itemize}

\begin{figure}[H]
\centering
\includegraphics[width=0.70\textwidth]{images/calls_tree.png}
\caption{Déroulage de l'arbre d'appels à partir du graphe
\ref{fig:call_graph}}\label{fig:call_tree}
\end{figure}

\subsection{La génération de rapports}
\label{sec:report_generation}

La majorité des vues proposées par la plate-forme présentent des données ayant
un intérêt statistique (Nombre de SLOC, nombre d'appels, complexité, etc
\ldots). A défaut de pouvoir proposer des fonctions de traitement statistique
avancées, il peut être intéressant de disposer de ces données de manières
à pouvoir les traiter avec des outils externes tels que \emph{Excel}. De ce fait
il est possible d'exporter la majorité des données présentées au format
\emph{CSV} reconnu par de nombreux logiciels gérant des tableurs. Ce format
montre sont intérêt par sa simplicité de génération; en effet il s'agit d'une
succession de lignes séparées en générale par des retours chariot; les
valeurs des colonnes étant quant à elles séparées par des virgules ou point virgules.

\subsubsection{Le modèle CSV}
\label{sec:csv_model}

J'ai donc mis au point une petite \textit{API} s'interfacant avec les vues de la
plateforme et permettant de générer des fichiers CSV à partir de différentes
sources. Le diagramme représenté par la figure \ref{fig:csv_model} décrit les
éléments principaux de cette \textit{API}.\\

\begin{itemize}
  \item \emphbf{CSVHeader}: Permet de décrire une colonne de notre
  fichier CSV. Il permet de donner un aspect sémantique aux données en les
  typant et de de déterminer le formatage à utiliser pour le rendu textuel.
  \item \emphbf{CSVModel}: Permet d'associer des données aux différentes
  entêtes. C'est l'élément variable dans le processus de génération de rapport
  CSV, on aura en effet un modèle par vue ou selon les informations que l'on
  souhaite générer.
  \item \emphbf{CSV}: Regroupe les données brutes du fichier CSV sous forme
  d'une succession de lignes. Une ligne étant représenté par un séquence de
  chaînes de caractère. On peut également remarquer une locale déterminant le
  séparateur à utiliser ou encore le format de rendu des réels.
  \item \emphbf{CSVCreator}: Permet de créer des \emph{CSV} à partir d'objets
  arbitraires en se basant sur un \emph{CSVModel}.
  \item \emphbf{CSVTableViewer}: Se base sur des modèles CSV pour présenter des
  données sous formes de tables, avec des actions prédéfinies permettant de
  gérer une selection de lignes (ex: export dans un fichier).\\
\end{itemize}

\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{images/csv_model.png}
\caption{Le modèle CSV}\label{fig:csv_model}
\end{figure}
